圖 1. Access Proxy (source: https://www.beyondcorp.com/)

上篇提到了 Access Proxy 擴充了 GFE 的功能：Authentication, Authorization, Centralized Logging。除此之外，Access Proxy 還具備一個特點——自助配置 (Self-service provisioning)。

本篇大部分爲論文翻譯，詳見出處：Google's frontend infrastructure: "The Access Proxy"

Features of the Access Proxy: Operational Scalability

自助配置 (Self-service provisioning)

一旦 Access Proxy 基礎架構就緒，企業應用程序的開發人員和所有者會有動力來配置後端服務以通過 Access Proxy。當 Google 逐漸限制用戶對企業資源的網絡級別訪問時，大多數內部應用程序的所有者都將 Access Proxy 視為最快的解決方案，以保持其服務可用。這也帶來了一個顯著的問題，Access Proxy 的配置需求大幅上升，處理 Access Proxy 配置的工作無法靠單一團隊完成。因此我們構建了 Access Proxy 的自助配置功能以促進自助添加 (self-service additions)。用戶保留其配置片段的所有權，而管理 Access Proxy 的團隊則負責整理、測試、發布配置。

這種設置有一些主要優點：

1. 使 Access Proxy 的擁有者不必不斷地根據用戶請求修改配置
2. 鼓勵服務所有者管理和擁有自己的配置片段（並為其編寫測試）
3. 確保在開發速度和系統穩定性之間達成合理的妥協

將服務設置在 Access Proxy 背後所需的時間實際上已經減少到了幾分鐘，同時用戶也能夠在其配置片段上進行叠代，而無需向管理 Access Proxy 的團隊請求支持。

最後，我們來讀 Google 在設計 Access Proxy 時的 lessons learned，作爲這個架構元件的小節。

Lessons Learned

1. Access Control List (ACL) 是種複雜的機制

我們建議采用以下最佳實踐來減輕與 ACL 相關的困難：

• 確保 ACL 語言是通用的。可以預期的是您將需要定期更改 ACL，並確保語言本身不會妨礙這些更改。
• 盡早啟用 ACL。這樣做的原因有兩個：
  • 確保用戶盡早了解 ACL 以及可能導致訪問遭拒的原因。
  • 確保開發人員開始調整其代碼以滿足 Access Proxy 的要求。例如，我們不得不實施一個 cURL 替代方案來處理用戶和設備身份驗證。
• Self-service provisioning。如前所述，處理 Access Proxy 配置的工作無法靠單一團隊完成。
• 創建一個從 Access Proxy 傳遞數據到後端的機制。如上篇所述，Access Proxy 可以安全地在傳遞給後端過程中附加數據，以允許後端執行精細的訪問控制。請提前計劃這個必要的功能。

2. 緊急情況不可避免

爲了處理不可避免的緊急情況，請制定經過測試的計劃 (well-tested plans)。請務必考慮兩大類緊急情況 (emergencies)：

• Production emergencies: 由「訪問路徑中關鍵元件的停機或故障」引起。
• Security emergencies: 由「緊急需要授予/撤銷對使用者/資源的訪問權限」引起。

2.1. Production emergencies

爲了確保 Access Proxy 能夠在停機情況下繼續提供正常服務，請根據 SRE 最佳實踐設計和運營 Access Proxy。SRE 最佳實踐請參考：B. Beyer, C. Jones, J. Petoff, and N. Murphy, eds., Site Reli-ability Engineering (O’Reilly Media, 2016)。

爲了應對潛在的數據源中斷，我們的所有數據都會定期快照，並在本地提供。我們還設計了不依賴於 Access Proxy 的 Access Proxy 修復路徑。

2.2. Security emergencies

Security emergency 比 production emergency 更微妙，因爲在設計整體訪問架構中它很容易被忽視。請務必在用戶/設備/會話的註銷 (user/device/session revocation) 過程中謹慎考慮 ACL 推送頻率和 TLS 問題。

用戶註銷相對簡單易懂：在註銷流程中，被註銷的用戶將被自動添加到一個特殊的群組中，ACL中的一個早期 Global rules 保證了這些註銷的用戶會被拒絕訪問任何資源。同理，session tokens（例如，OAuth 和 OIDC tokens）和證書有時也會泄漏或丟失，因此需要被註銷。

正如在第一篇論文中討論的那樣（而我們鐵人挑戰賽還沒講到，不過沒關係先看下去），在設備庫存管道 (device inventory pipeline) 回報前，設備標識符 (device identifier) 是不可信的。這意味著即使失去了證書頒發機構（CA）密鑰（這意味著無法撤銷證書），也不意味著失去控制，因為新的證書在被正確編入庫存管道之前是不受信任的。

鑒於這種能力，我們決定完全忽略證書撤銷 (certificate revocation)：我們不發布證書撤銷列表（CRL），而是將證書視為不可變的，並且只有在我們懷疑相應的私鑰丟失或泄漏時，才會降低 device inventory 的信任級別 (trust tier)。從本質上來說，device inventory 充當設備標識符 (device identifier)的白名單，對 CRL 沒有實時依賴性。這種方法的主要缺點是可能引入額外的延遲。但是這種延遲相對容易解決，只要在 device inventory 和 Access Proxy 之間加快連接速度即可。

爲了確保及時的 policy enforcement，您需要一種用於 ACL 的標準、快速推送流程。在達到一定規模之後，您肯定會需要將少部分的 ACL 定義過程委托給服務所有者，而這將導致不可避免的錯誤。雖然單元測試和冒煙測試 (Smoke Testing)通常可以捕捉到明顯的錯誤，但邏輯錯誤會繞過安全保障並進入生產環境。工程師能夠迅速回滾 ACL 以恢覆丟失的訪問權限或 lock down 意外的廣泛訪問權限非常重要。就像我們之前的零日漏洞插件範例一樣，我們能夠迅速推送 ACL 對於我們的事件響應團隊至關重要，因為我們可以迅速創建自定義的 ACL 來強制用戶進行瀏覽器更新。

3. Engineers need support

向 BeyondCorp 世界過渡並非一朝一夕之事，需要多個團隊之間的協調和互動。在大型企業中，不可能將整個過渡工作委托給單一團隊。過渡的過程可能涉及一些不向後兼容的更改，這需要足夠的管理層支持。

過渡的成功與否在很大程度上取決於團隊成功將其服務設置在 Access Proxy 之後的難易程度。讓開發人員的工作更輕松應該是首要目標，因此要盡量減少意外情況發生。提供合理的默認設置，為最常見的使用案例創建詳細指南，並編成文檔。為高層級和覆雜的更改提供沙盒環境，例如，您可以設置 Load Balancer 打不到但開發人員可以直接訪問的 Access Proxy instance。沙盒在許多情況下都被證明非常有用，比如在 X.509 證書或底層 TLS 庫發生重大變更後，我們需要確保客戶端能夠處理TLS連接。

=============我是活下來了的分割線=========================

至此，Access Proxy 告一段落。撒花！！!

明天我們看下一個組件：Access Control Engine。拜拜！